home *** CD-ROM | disk | FTP | other *** search
- Good news for mousee-haters. Have your shell within a GEM application too!
-
- Description:
-
- NutShell v 1.0 (30-mar-1989) is NOT a shell. It merely is an interface to a
- running shell using a system() call over the _shell_p pointer (used in
- GPshell and Gulam, maybe others). (It can Pexec a shell as well, but this is
- of course much slower and much more likely to crash the open application.)
- This means that when a shell implementing the _shell_p mechanism is running
- NutShell will give you all its power within a GEM applications. It has been
- tested with the GPshell of the CRAFT package, but should work with (among
- others) Gulam as well. It is written in Turbo-C using the CRAFT system.o and
- will run both as an accessory (nutshell.acc) and as a program (nutshell.prg).
- Just change the extension.
-
- Memory requirements:
-
- NutShell has been kept as small as possible, so that TeX and other
- notoriously big programs can run even in its presence. The static size is
- about 7K. However, when running it needs a few extra K to store the menu
- bar, and the GPshell will not do anything without 17K free memory. Most GEM
- applications just take all available memory. A mechanism for grabbing memory
- from GEM applications, but not from tex.ttp, has been implemented using the
- command
- $ malloc n
- This will make the NutShell reserve n Kbyte every time you log out and every
- time it receives an AC_CLOSE (accessory close) signal. This signal normally
- arrives only when a new GEM application starts, as the GPshell keeps total
- control in the meantime and does not give AES a chance to do anything. This
- way any GEM application will have to give up n K, whereas a TOS program has
- all space (yes, I know, dirty).
-
- Hence: start up a GEM application that leaves memory (UniTerm with the system
- buffer set to >20 K, desk.prg, tcbsp4.prg, Tools dvi.prg before format/start,
- ...), start NutShell, type malloc n (n > 17), type lo, exit the application
- and all is set up. You can also do this from the desktop, but then you will
- permanently lose the n K.
-
- Features:
-
- A history of 1 has been built in. The arrow keys and ^U, ^T work as in the
- GPshell. Function keys are passed as $PFn, so that the GPshell mechanism for
- defining function keys still works (NB. do not use "set PFn = 'aap noot
- mies'" but "set PFn = ( aap noot mies )"). PF20 is interpreted as 'lo', as
- in STedi. Filename completion is not supported, nor are csh-like history
- references (such as '!e'). For multiline commands use <lf> to seperate:
- '$ foreach file ( * ) ^J echo $file ^J end'.
-
- You can change the standard shell to be Pexec'd and its home directory from
- the desktop using a binary editor, extra space has been reserved. An easy
- way to get an interactive shell is to start nutshell.prg from the accessory.
-
- Problems:
-
- Only works on a standard screen. Internal shell commands work great as long
- as they are accessible over the system() interface (not: ramdisk, cache,
- font, logout, lpr, lprm, moreheap, mouse (in the GPshell)). Running an
- external program from an accessory is a risky business. I found with this
- version (1.0) there are three kinds of applications:
-
- - normal: (desk, tcbsp4, Kettler previewer): TOS programs will run OK,
- anything even remotely using GEM (including STedi) will crash GEM when
- exiting the application.
-
- - weak: (UniTerm 2.0c, tc.prg): Running ANY program will crash UniTerm and
- tc.prg. However, both of these allow an external program to be run
- directly: rename nutshell.acc to nutshell.prg and run.
-
- - strong: (Tools dvi.prg): STedi.prg seems to run OK, of course full GEM still
- is a no-no.
-
- I hope to include info on more combinations in the future, please report
- problems to me.
-
- Geert Jan van Oldenborgh,
- Ank van der Moerstraat 24,
- NL-2331 HS Leiden,
- tel 071-317512.
- t19@nikhefh.hep.nl
-